Many areas including Investigative Analysis and Business Intelligence gathering involve the construction of complex models of a problem domain, and the creation of inquiries for new information about the domain being investigated. Constructing such inquiries can often be difficult and disruptive to the process of modeling the problem domain. Because constructing new inquiries from scratch can be difficult, investigators often attempt to construct new inquiries by copying similar inquiries from previous models and modifying them to suit the current investigation context. However, the process of locating an appropriate old inquiry to copy, and determining which aspects of the old inquiry need to be changed to suit the current investigation, can itself be disruptive to the modeling process.
Templates are a common solution in other situations where old items are copied to create new instances. Just as illustration, Microsoft SQL server ships with a catalog of a few dozen templates for common types of SQL queries. A user creating a new SQL query can simplify the task by building upon an existing template. Similarly, many email clients allow the creation of templates for common types of emails, where only a few things, such as the name of the recipient and their email address needs to be changed. In this standard notion of templates, the template can typically be thought of as a string with parameters (this is also a frequently used implementation strategy); which must be changed to suit the context in which the template is being used.
Typically, templating involves a two-stage process of creation and use. In the first step, a concrete instance of an item is taken as the basis for creating a template by generalizing some of its aspects by parameterizing them. This is notated:                Template creation: Concrete item A→Template (formed by generalizing some aspects of A as “parameters” in the template)Templates created in this way are stored in a catalog.        
In the second step, a template is chosen from the catalog and a new item is created from the chosen template by associating concrete values with the parameters:                Template use: Template→new concrete item B (formed by associating new values for the template's parameters)        
In situations where the task of choosing and applying a template is a first class activity that is not subordinate to another higher-level activity, this simplistic model of templates may be adequate. For instance, for a user who wants to send out a mass email of a certain type, choosing which email template to apply is the most important activity in the context. Similarly, in some situations, such as creating a new table, choosing the SQL template to apply is the most important activity. In other cases, such as choosing an appropriate SQL query to run to retrieve data relevant to a business problem, stopping to choose the appropriate SQL template to apply for the query can be a distraction from focusing on the business problem at hand.
When choosing a template is a subordinate activity to a higher-level activity that also demands the attention of the user, the number of inquiries and templates in the catalog can quickly get out of hand. In Applicants' situation, searching for the appropriate template to use in the context of the model can itself disrupt the modelling process the modeller is carrying out. Furthermore, even if an appropriate template is found, applying it involves replacing the parameters of the templated inquiry. These are typically low-level attributes of the objects being modelled; thus the modeller will have to typically switch context yet again to figure out the values to associate with the parameters.
Three examples of related art are as follows.
SPRAUL: The SPARQL update language is defined by HP Labs and specifies changes to an RDF graph as templates of other RDF graphs. This looks and feels a lot like SQL, and is too low-level for the purposes of modellers. This involves thinking about the model in terms of RDF whereas Applicants allow modellers to think in terms of a graphical and English-like textual representation. Furthermore, semantic type information is not well exploited to suggest possible templates to apply in any given context. See <jena.hpl.hp.com/.about.afs/SPARQL-Update.html> for a brief summary or <www.hpl.hp.com/techreports/2007/HPL-2007-102.pdf>, for a full report.
S-F. Chen, W. Chang, H. Sundaram, “Semantic visual templates: linking visual features to semantics” in 1998 International Conference on Image Processing (ICIP '98)—Volume 3 p. 531, or <ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=727321> is another example. This paper uses semantic annotations to retrieve images. In this way, they are arguably superficially similar to Applicants' method of retrieving templates appropriate to the modeling context. However, they do not exploit type hierarchy information; and also, their application does not require the second step of applying the template in the context of a model, where Applicants further use object-level information to automatically fill in parameters.
IBM Semantic Tools for Web Services at <www.alphaworks.ibm.com/tech/wssem/> includes functionality for adding semantic annotations and matching between Web Service Interfaces that have different names but have compatible annotations. This is similar to Applicants' method for matching applicable templates given a modeling context, but should be more appropriately compared to matching two different templates based on their annotation. This technology for matching can be profitably used in conjunction with Applicants' invention to compose two different inquiries together into a more complex inquiry.